Multiple Inheritance לאוניד ברנבוים המחלקה למדעי המחשב אוניברסיטת בן-גוריון

Transcription

1 Multiple Inheritance לאוניד ברנבוים המחלקה למדעי המחשב אוניברסיטת בן-גוריון

2 22 Roadmap In this chapter we will investigate some of the logical problems that can arise when a language allows a child class to have multiple parents: Name ambiguity Impact on substitution The Problem of Common Ancestors Implementing multiple inheritance in Java

3 33 Inheritance as Categorization

4 44 Inheritance as Categorization In one sense, the process of inheritance is a form of categorization A TextWindow is a type of Window, so class TextWindow inherits from class Window But in the real world, most objects can be categorized in a variety of ways

5 55 Inheritance as Combination Instead, real world objects are combinations of features from different classification schemes Each category giving some new insight into the whole: Moshe is Male Moshe is Israeli Moshe is a Parent Moshe is a Professor Note that we have not lost the is-a relationship; it still applies in each case

6 66 Inheritance as Combination Parent Male Professor Israeli

7 77 Is-a, Has-a, and As-a A common analogy in describing multiple inheritance is that of an actor playing different roles Often at the same time Likewise, multiple inheritance is not has-a and not quite the is-a relationship (because the parent class is no longer unique) But a variation of the is-a that could be described as as-a Rule of thumb: use multiple inheritance if the A can be viewed as-a B sounds right

8 88 CS Example - Complex Numbers Two abstract classifications: Magnitude - things that can be compared Number - things that can perform arithmetic Three specific classes: Integer - comparable and arithmetic Char - comparable but not arithmetic Complex - arithmetic but not comparable

9 99 Possible Solutions 1. Make Number subclass of Magnitude, but redefine comparison operators in class Complex to give error message if used (subclassing for limitation) 2. Don't use inheritance at all - redefine all operators in all classes (flattening the inheritance tree) 3. Use part inheritance, but simulate others - use Number, but have each number implement all relational operators (partial flattening) 4. Make Number and Magnitude independent, and have Integer inherit from both (multiple inheritance)

10 10 Inheritance as a form of Combination Char Magnitude Number Integer Complex This reflects the as-a relationship in a natural way

11 11 Another Example - Walking Menus A Menu is a structure charged with displaying itself when selected by the user A Menu maintains a collection of MenuItems Each MenuItem knows how to respond when selected A CascadingMenu is both a MenuItem and a Menu

12 12 Problem with Multiple Inheritance - Name Ambiguity What happens when the same name is used in both parent classes: A CardDeck knows how to draw a Card A GraphicalItem knows how to draw an Image on a screen A GraphicalCardDeck should be able to draw Which? CardDeck draw() GraphicalObject draw() GraphicalCardDeck?

13 13 Solution A Explicit disambiguation: GraphicalCardDeck gcd; gcd.carddeck::draw(); gcd.graphicalobject::draw(); This solution is less than ideal, since the syntax is different from other function calls, and programmers must remember which method comes from which parent

14 14 Solution B With different type signatures, can use straight overloading: class GCD : public CardDeck, public GraphicalObject { public: virtual Card *draw(){ return CardDeck::draw(); ; virtual void draw(graphicscontext *g){ GraphicalObject::draw(g); ; ; If the type signature are similar, or if overloading is not allowed, then the programmer is faced a more difficult decision.

15 15 Solution C Redefine one or the other operation in the child class: class GraphicalCardDeck : public CardDeck, public GraphicalObject { public: virtual void draw () { return CardDeck::draw(); virtual void paint () { GraphicalObject::draw(); GraphicalCardDeck gcd; gcd->draw(); // selects CardDeck draw gcd->paint(); // selects GraphicalObject draw

16 16 Problem with Redefinition Solution The redefinition solution is not without cost What happens when we run up against the principle of substitution? GraphicalObject *g = new GraphicalCardDeck(); g->draw(); // opps, doing wrong method! This problem can be mitigated, but the solution is complex and not perfect (see next slide)

17 17 A (complicated?) solution class CardDeckParent : public CardDeck { public: virtual void draw() {carddeckdraw(); virtual void carddeckdraw() {CardDeck::draw() class GraphicalObjectParent : public GraphicalObject { public: virtual void draw() {godraw(); virtual void godraw() {GraphicalObject::draw() class GraphicalCardDeck: public CardDeckParent, GraphicalObjectParent { public: virtual void carddeckdraw() { virtual void godraw() { // All three variables refer to the same object GraphicalCardDeck *gcd = new GraphicalCardDeck(); CardDeck *cd = gcd; GraphicalObject *go=gcd; cd->draw(); // ok, will execute carddeckdraw go->draw(); // ok, will execute godraw gcd->draw(); // compiler error, ambiguous invocation

18 18 A solution in C# class GraphicalCardDeck : CardDeck, GraphicalObject { void CardDeck.draw() { void GraphicalObject.draw() { public void draw() { GraphicalCardDeck thedeck = new GraphicalCardDeck(); thedeck.draw(); // Executes method #3 CardDeck cd = (CardDeck) thedeck; cd.draw(); // Executes method #1 GraphicalObject go = (GraphicalObject) thedeck; go.draw(); // Executes method #2

19 19 Other Approaches to Name Ambiguity Other languages use different approaches to solving the problem of ambiguous names: Eiffel uses the ability to rename features from the parent class A polymorphic variable accessing through the parents name will access the renamed feature in the child (see next slide) LISP and Python resolve ambiguous names by the order in which the parent classes are listed The first occurrence of the name found in a systematic search is the one selected

20 20 Methods redefinition in Eiffel Eiffel allows to directly redefine a method in the sub-class by renaming it in the inherit clause: class GraphicalCardDeck inherit CardDeck rename draw as carddeckdraw end GraphicalObject rename draw as godraw end The solution is roughly equivalent to helper renaming (having a specific parent for each inherited copy) But more efficient and does not require extra classes

21 21 Multiple Inheritance of Interfaces Multiple inheritance of interfaces does not present the same problem of name ambiguity as does multiple inheritance of classes: Either the ambiguous methods in the parent classes have different type signatures, in which case there is no problem, or The ambiguous methods in the parent classes have the same signature Still no problem, since what is inherited is only a specification, not an implementation This is why Java permits multiple inheritance of interfaces, not of classes Nevertheless, C# does not permit the same method name to be inherited from two parent interfaces.

22 22 Inheritance from Common Ancestors Does the new object have one or two instances of the ancestor? A A A B C B C D D

23 23 Sometimes: one instance of the ancestor

24 24 Sometimes: two instances of the ancestor class Link{ public: Link *nextlink; class CardDeck : public Link { ; class GraphicalObject : public Link{ ; Presumably, the lists of card decks and graphical objects are distinct, and hence each type of list should have its own links

25 25 Data Field in Common Ancestor Imagine that the common ancestor declares a data member Should the child class have one copy of this data field, or two? Both answers can be justified with examples C++ gets around this by introducing the idea of a virtual parent class: If your parent is virtual there is one copy, and if not there are two Not a perfect solution, and makes the language complicated

26 26 Virtual Inheritance class Stream {...; class InStream: public virtual Stream {...; class OutStream: public virtual Stream {...; class InOutStream: public InStream, public OutStream {...; The ambiguity occurs in InOutStream, But the solution involves the definitions of InStream and OutStream

27 27 Inner Classes The ability to nest classes in C++ and Java provides a mechanism that is nearly equivalent to multiple inheritance, without the semantic problems: class Child extends ParentOne {... class InnerChild extends ParentTwo {... // can access both parents Within the inner class you can access methods from both parent classes This idiom is used a lot in Java. Solves many problems that would otherwise be addressed using multiple inheritance Not exactly equivalent to multiple inheritance, but very close

28 28 Delegation Simulating Multiple Inheritance with Interfaces Using interfaces and fields can simulate multiple inheritance. For example, we would like class C to extend both A and B Impossible multiple inheritance in Java: class A { public void foo() {... class B { public void goo() {... class C extends A, B { // Not allowed in Java!

29 29 Delegation An alternative mechanism for extending classes To make class C extend" B: 1)Define an interface BInf that includes all the public methods of B 2)Make classes B and C implement BInf 3)Add a field of type B to class C 4)Implement BInf in C by delegating all the messages to the new field

30 30 Delegation A Delegation example in Java class A { public void foo() {... interface BInf { void goo(); class B implements BInf { public void goo {... class C extneds A implements BInf { private B _b; public void goo() { _b.goo();

31 31 Chapter Summary In this chapter we have explored some of the problems that arise of the concept of multiple inheritance: Name ambiguity Impact on substitution The problem of common ancestors Implementing multiple inheritance in Java